perm filename MLIBRT.PUB[HAL,HE] blob
sn#133588 filedate 1974-12-04 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00004 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 .lib:NEWSS LIBRARY ROUTINES
C00010 00003 .NEWSSS SAVING LIBRARY ROUTINES
C00013 00004 .NEWSSS SAVING AND RESTORING PLANNING VALUES
C00015 ENDMK
C⊗;
.lib:NEWSS LIBRARY ROUTINES
Many of the applications for which AL is intended characteristicly
involve repeating a number of very similar subtasks. For instance,
an assembly program might have to change sockets on an electric
driver many times in order to drive down a number of different bolts.
If written in "simple" AL, with each such subtask coded out in
explicit statements like MOVE and OPERATE, such programs would be
very tedious to write and debug. On the other hand, the necessity of
planning motions frequently makes procedures (in the traditional
sense) infeasible. To overcome this difficulty, AL provides a
facility for "routines", which externally resemble macros, in that
they are "expanded" each time they are invoked, although they are
are stored and manipulated by the compiler in a somewhat more
efficient manner. The AL system will include a predefined library
of routines for performing a number of commonly useful functions,
although a user can, of course, "roll his own" by using the ROUTINE
construct, which has the form
.UNFILL
ROUTINE <id> (<parameter list>);
<body>
.REFILL
where the <parameter list> syntax is the same as for procedure
definitions, and the <body> may be either an expression or a
statement. When the library routine is expanded, all instances of the
parameter names are substituted with the actual parameters supplied
in the call. Thus, a typical library routine declaration might look
like:
.UNFILL
ROUTINE reach(SCALAR thickness;FRAME place);
BEGIN
.COMT 16
α{causes the hand to move to the indicated
spot, and keep opening & closing its fingers
until something is put in themα}
.END
SCALAR flag;
MOVE YELLOW TO place;
flagα←1;
WHILE flag ≠ 0 DO
BEGIN
OPERATE YFINGERS WITH OPENING = 5;
OPERATE YFINGERS WITH OPENING = thickness-.1
ON YTOUCH DO
BEGIN
flagα←0;
STOP;
END;
END;
END
.REFILL
Library routines without parameters are invoked simply by including
their name in the source program. For instance, suppose we have a
library routine PARK_YELLOW which parks the yellow arm. Then
.UNFILL
IF h>3 THEN
PARK_YELLOW
.REFILL
might expand into something like
.UNFILL
IF h>3 THEN
MOVE YELLOW TO YPARK
.REFILL
There are several ways to specify parameters. Perhaps the
simplest is to follow the syntax for procedure calls, in which case
the arguments must correspond in order and type with those in the
statement which defined the routine. For example,
.UNFILL
reach(0.5, FRAME(ROT(Z,90*DEG),VECTOR(1,2,3)))
.REFILL
This can become very inconvenient for routines which have a large
number of parameters, since the user may have trouble remembering the
correct order, or may want to leave some unspecified. These
difficulties are avoided by using the form
.UNFILL
reach(thickness = 0.5, place = FRAME(ROT(Z,90*DEG),VECTOR(1,2,3)) )
.REFILL
It is possible to specify default values for parameters to library
routines by including the construct
.UNFILL
(DEFAULT <value>)
.REFILL
after the parameter name in the formal parameter list for the routine.
For example,
.UNFILL
ROUTINE reach(FRAME arm(DEFAULT YELLOW),place;
SCALAR thickness(DEFAULT 0));
BEGIN
:
END
:
reach(BLUE,f1); α{%4A thickness of 0 is assumed.%*α}
reach(place=f2,thickness=10); α{%4YELLOW arm assumed.%*α}
.REFILL
The construct
.UNFILL
SPECIFIED(<parameter id>)
.REFILL
may be used in a compile-time conditional to test whether the named
parameter has been assigned a value. For example,
.UNFILL
ROUTINE transmogrify(ATOM errdev;...);
BEGIN
.COMT 16
α{Note here that the atom
errdev is merely being used as a name
passing mechanism.α}
.END
:
IF errcond THEN
BEGIN
PLAN IF SPECIFIED(errdev)
THEN OPERATE #(errdev)
ELSE ABORT
END;
:
END;
.REFILL
If a parameter has no default value specified and is not bound by the
call, then any expansion of the routine that uses the parameter will
result in an error; occurrences of an unbound parameter in the unexpanded
part of a planning conditional are legal.
Yet another syntax is acceptable for invocation of library routines;
it is included for compatibility with high level primitives (see
{secref vhl}). In this form, the parameter names act like key words
identifying various clauses in a "pseudo-english" statement, as in
.UNFILL
REACH thickness 0.5 place FRAME(ROT(Z,90*DEG),VECTOR(1,2,3))
.REFILL
If a parameter to a routine occurs in the body in some construct
where a variable must occur (eg. the left hand side of an assignment
statement), the compiler will do the "right" thing when the
corresponding actual parameter is a constant or expression: a
warning will be printed, and the compiler will invent a temporary
variable to hold the value.
.NEWSSS SAVING LIBRARY ROUTINES
Library routines may be saved on a file by use of the statement (and
supervisor command)
.UNFILL
SAVE <flag> <routine name list> ON <file specifier>
.REFILL
where <flag> may be either NEW, OLD, or <empty>. For instance,
.UNFILL
SAVE reach, transmogrify ON "FEE.FIE[FO,FUM]";
SAVE OLD foobaz ON "DEFS.1[II,HE]";
SAVE NEW grab1, grab2, grab3 ON "GRABS";
.REFILL
IF <flag> is <empty> and one of the named routines already exists on
the specified file, the old definition is overwritten. IF <flag> is
NEW, then only routines which do not already exist on the specified
file will be added. Similarly, if <flag> is OLD then only routines
which are already on the file will be saved. If the <routine name
list> is omitted, then all existing routines will be saved on the
specified file. E.g.
.UNFILL
SAVE ON "DEFS.ALL";
SAVE NEW ON "DEFS.2";
.REFILL
Library routines may be retrieved from a file by the command
.UNFILL
RETRIEVE <flag> <routine name list> FROM <file specifier>
.REFILL
If <flag> is empty, then the specified routines will be retrieved
from the specified file. If, however, <flag> is NEW, then only
routines which are not already defined will be read in; if <flag> is
OLD, then only routines which are already defined will be retrieved
(they will be redefined). If the <routine name list> is <empty>,
then all routines on the file will be read (subject to any
restrictions imposed by <flag>). Examples:
.UNFILL
RETRIEVE FROM "DEFS.RCB";
RETRIEVE Aeneas, Dido FROM "CAVE";
RETRIEVE NEW FROM "AL.LIB[AL,HE]";
.REFILL
.NEWSSS SAVING AND RESTORING PLANNING VALUES
The statement SAVE WORLD ON W1 will cause the "world" at
that point in the planning to be written out into a file called
W1.WLD. The statement RETRIEVE WORLD FROM W1 will read in this file
and set up the world as it was when saved.
The world includes all planning values and all assertions. It does
not include defined library routines.
Saving the world is particularly
useful for recovering when the arm runs into trouble; it makes it
unnecessary to begin the planning from scratch.
It is also possible
to improve the planning values of frames after a period of execution;
this is done by the statement RESTORE WORLD FROM RUNTIME.
The effect of this is that all the variables which the runtime knows
about are read, and their values become the new planning values
for those variables.